1. Field of the Invention
This invention relates generally to the field of computer memory mapping and more particularly to mapping logical and physical driver objects corresponding to device drivers.
2. Description of the Related Art
An application running on a conventional computer system having a processor and an operating system communicates with an operating system module ("graphics module") to request that graphics be displayed on a monitor or printed by a printer coupled to the computer system. In certain operating systems, such as a "MICROSOFT" "WINDOWS" operating system, such a module is called a Graphics Device Interface (GDI). In order to execute the graphics command from the application, the graphics module communicates with a display driver or printer driver ("device driver"). Device drivers are utilities an operating system uses to communicate with specific hardware components. Many device drivers are distributed along with operating systems, while others are distributed with the hardware components they drive. With respect to display monitors and printers, the associated device drivers control the actual display or printing, respectively, of the graphics specified by the application, such as by controlling memory updates of buffers that reflect what is being exhibited on a monitor or printed.
As shown in FIG. 1, conventional application 21 communicates with graphics module 14 of operating system 27 using one or more graphics objects in logical driver object form. For example, application 21 could instruct graphics module 14 to draw a line on a graphics component such as a monitor or printer using a certain graphics object, such as a red pen. Such a communication typically would be in the form of a logical driver object. The contents, i.e., the data within the logical driver object, can be created by the application or else are readily identifiable such that an application programmer knows what to create or which logical driver to use in communicating with graphics module 14 to obtain a desired result, such as the drawing of a red line in a graphics environment.
Graphics module 14, in turn, instructs device driver 16 using a physical driver object, which is a graphics object in device-dependent format. For proper graphics communications to occur, the physical driver object used must be one which corresponds to the content of the logical driver object used by application 21. Typically, physical driver objects are created by device driver 16. In "MICROSOFT" "WINDOWS" operating systems, the physical driver object is created when the logical driver object is selected into a device context. A device context is the environment in which graphics action occurs, such as a memory buffer, bitmap, video monitor or portion of a video monitor.
A particular physical driver object has significance to the device driver that created it. To most other software modules or hardware devices, physical driver objects are unidentifiable blocks of binary data. However, graphics module 14 has an ability to correlate the contents of the logical driver object used by a communicating application with a corresponding physical driver object used in subsequent communication with the device driver. When application 21 calls graphics module 14 with a particular logical driver object, more specifically, the contents of a particular logical driver object, the parameters of which define, for example, a red pen, graphics module 14 communicates with device driver 16 using a corresponding physical driver object, assuming device driver 16 already has created the physical driver object.
The limited ability of any mechanism except for graphics module 14 of operating system 27 to associate a physical driver object with the contents of a logical driver object presents a problem in the field of application sharing. In application sharing, an application resides in memory on a host and is shared with one or more guest computers. Each of the host and guest(s) include operating systems. The host and guest(s) also are provided with application-sharing software. The application-sharing software allows the host and guest(s) to share the application, for example over a network coupling.
In a typical application-sharing configuration, the host application-sharing software monitors entry points in device driver 16 used by graphics module 14. Whenever graphics module 14 calls device driver 16, for example to execute graphics activity, the host application-sharing software is privy to the call and knows that some graphics activity has been specified. The call from graphics module 14 to device driver 16 is based, however, on the device-dependent physical driver object. Generally, as noted above, such objects are unidentifiable blocks of binary data. Thus, host application-sharing software is limited in its ability to determine what the shared application has commanded a host graphics component to do, unless the physical driver object used by graphics module 14 can be associated with corresponding and identifiable logical driver contents, which define the parameters of the graphics object being used. Without knowing what the host graphics component has been commanded to do, the host application-sharing software will be unable to instruct the guest application-sharing software to correspondingly interact with the graphics module in the guest's operating system to identically update a guest graphics component.
Certain conventional application-sharing systems require that application sharing commence, i.e., the software that enables application sharing begin running, before or at the same time as the shared application. Because a physical driver object is not created, or "realized", until an application calls an operating system's graphics module using an associated logical driver object or, in "WINDOWS" operating systems, until an associated logical driver object is selected into a device context, it is possible to overcome limitations in conventional application-sharing systems by activating application-sharing before or concurrently with a shared application. By an application-sharing before an application has had an opportunity to create or realize physical driver objects, the generation of physical driver objects as they are created during normal shared application execution can be observed by host application-sharing software. The host application-sharing software thus readily can associate the physical driver objects as they are created with logical driver content, and can identify for application-sharing software on the guest the logical content of the physical driver objects, to inform the guest of the parameters of the graphics object being used for the graphics activity.
Other conventional methods involve a somewhat unsophisticated rummaging through private, undocumented data structures associated with a graphics module. Through empirical analysis, based on observations of activities associated with the graphics module, and through information generally known about an operating system, it is possible to relatively thoroughly establish relationships between the contents of logical driver objects and physical driver objects to an extent sufficient to enable relatively accurate application sharing. However, this method is subject to a slight degree of error, since a possibility exits that the logical content of every physical driver object might not be accurately established. Furthermore, the relationships so established are necessarily unique to particular operating systems and must be repeated to establish relationships for different operating systems and different revisions of operating systems. This obviously is inefficient with respect to time and cost.
A method is needed, therefore, for accurately and automatically identifying a correspondence between a physical driver object and the contents of one or more logical driver objects. The method should be executable at any time, even after an application has been running and some or all physical driver objects already have been created or "realized" by device drivers. The method should avoid invading and empirically studying private data structures within an operating system's graphics module.